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REMARKS* 

Applicant responds to the Final Office Action mailed on June 2, 2004 within two 
months of the mailing date. Claims 1-38 were pending in the application and the 
Examiner rejects claims 1-38. Upon entry of the foregoing amendments, claims 1-5, 39 
and 40 remain pending in the application and Applicant cancels claims 6-38 without 
prejudice or estoppel from filing one or more claims with similar subject matter in one or 
more applications. After review of the above amendments and remarks below, 
reconsideration is respectfully requested. Applicant also submits herewith an RCE. 

The Examiner rejects claims 1-5 and 12-26 under 35 U.S.C. 1 12, first paragraph, 
as failing to comply with the enablement requirement. Examiner states, ". . .a form 
comprising an authorization is interpreted as a form with entry value indicative of 
security processor authorization such as a digital signature or time stamp." Applicant 
asserts that the "form" of the present invention includes data that authenticates a 
transaction such as, for example, a transaction authorization code, wherein the code may 
be a digital signature or timestamp. Nonetheless, to expedite prosecution of this 
application, Applicant amends the claims to clarify that authentication data is associated 
with the form. 

The Examiner next rejects claims 1-5, 12-26, and 27-38 under 35 U.S.C 102(e) as 
being clearly anticipated by Daly et al. (Daly), U.S. Patent No. 5,878,141. Applicant 
respectfully traverses this rejection. The Examiner asserts that because the forms of the 
present invention are "passive in that they are not sent or received", the "forms" are 
inherently comparable to the teachings of Daly in figure 5. To expedite prosecution of 
this matter, Applicant amends the claims to clarify that at least one form is provided to 
the merchant server. The present specification at, for example Page 10, Line 34 to Page 
11, Line 1, clearly teaches that forms are both sent and received ("Wallet server 140 then 
completes an authorization form and transmits the form to a merchant server 130." 
(emphasis added)). Moreover, at Page 11, Lines 17-21, the specification states that "In 
step (240), the wallet server 140 receives transactional authentication, completes an 
authorization form for the transaction and transmits the form to the merchant server 130. 
In step (250), the merchant server queries the security server for credit supplier 
authentication of the authorization form." (emphasis added). 
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Daly may perform two "authentication steps", but Daly does not include the step 
of assembling a form at a wallet server and transmitting the form to a merchant server, 
independent of the user. In other words, a wallet server which creates a form out of view 
of the user is not only more convenient for the user, but reduces opportunities for 
fraudulent purchases. Moreover, in the Daly system, the merchant may need different 
software and/or hardware to acquire data from different smart cards. In contrast, the use 
of a wallet server in the presently claimed invention reduces or eliminates this problem 
because one wallet server includes software and/or hardware to acquire data from 
different smart cards, without the need to install new software and/or hardware at each 
merchant system for reading different smart cards. Furthermore, the use of authentication 
data associated with the form in the presently claimed invention may allow the merchant 
to consider the transaction a "card present" transaction which significantly changes the 
risk allocation. 

Furthermore, the wallet server of the present invention generates and transmits an 
form including authorization data based on authorization information returned from a 
security server and transmits the form to a merchant. The authorization of a form as 
taught in Daly is different than the presently claimed invention in that the purchasing 
customer in the presently claimed invention does not complete an authorization form and 
submit it to an authorization server. An authorization form in the present invention is 
compiled at the wallet server and transmitted to a merchant system. The merchant 
system uses the data contained in the form to transmit a request to an authorization 
server. As set forth in the specification at, for example page 11, lines 17-20, "In step 
(240), the wallet server 140 receives transactional authentication, completes an 
authorization form for the transaction and transmits the form to the merchant server 130". 
As such, Daly does not disclose or suggest, for example, "associating authentication data, 
by said wallet server, with at least one form" or "providing said at least one form to a 
merchant server to facilitate merchant server using said at least one form to obtain an 
authorization from said security server" as similarly required in the present claims. 

The Examiner next rejects claims 6 and 8-1 1 are rejected under 35 U.S.C. 102(e) 
as being clearly anticipated by Gifford, U.S. Patent No. 6,049,785. Applicant 
respectfully traverses this rejection. Moreover, Applicant cancels claims 6 and 8-1 1, so 
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these rejections are now moot. However, to expedite prosecution of this case, Applicant 
asserts that the second verification as taught by Gifford only verifies that an order is used 
only once. This is very different than the second authorization step of the present 
invention. The second authorization as disclosed in the presently claimed invention uses 
authorization data which has been compiled at a wallet server and transmitted to a 
merchant server. The merchant server than uses the form data to perform a second 
authorization of the purchase transaction. Gifford does not teach or suggest a second 
authorization between a merchant server to a security server of a purchase transaction, 
only that it is not a repeat transaction. Additionally, according to Figure 5 of Gifford, the 
first authorization occurs between a buyer computer and a payment computer 54. This is 
contrary to the first authorization as presented in the present invention wherein in certain 
embodiments, a first authorization occurs between a wallet server and a security 
server/credit provider. As stated in the specification at, for example page 11, lines 16-17, 
"The wallet server 140 interfaces at step (220) with a security server to authenticate the 
transaction." As such, there is a critical difference between the first authorization of the 
present invention and the first authorization as taught in Gifford. Gifford teaches a first 
authorization as occurring between a buyer computer and a payment computer and not 
between a wallet server and a security server, as set forth in embodiments of the present 
invention. As such, Gifford does not disclose or suggest, for example, "associating 
authentication data, by said wallet server, with at least one form" or "providing said at 
least one form to a merchant server to facilitate merchant server using said at least one 
form to obtain an authorization from said security server" as similarly required in the 
present claims. 

The Examiner next rejects claim 7 under 35 U.S.C. 103(a) as being unpatentable 
over Gifford, U.S. Patent No. 6,049,785. Applicant respectfully traverses this rejection. 
The Examiner contends that Gifford teaches the use of a smartcard and that it would be 
obvious to open a wallet and input a smartcard in order to authenticate a transaction 
(column 10, lines 23-26). As set forth in the above arguments, the Gifford system is 
substantially different than the presently claimed invention and Gifford does not disclose 
or suggest, for example, "associating authentication data, by said wallet server, with at 
least one form" or "providing said at least one form to a merchant server to facilitate 
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merchant server using said at least one form to obtain an authorization from said security 
server" as similarly required in the present claims. 

Applicant respectfully submits that the pending claims are in condition for 
allowance. No new matter is added in this Response. Reconsideration of the application 
is thus requested. The Commissioner is hereby authorized to charge any fees which may 
be required, or credit any overpayment, to Deposit Account No. 19-2814. A duplicate 
copy of this sheet is enclosed. Applicant invites the Office to telephone the undersigned 
if the Examiner has any questions regarding this Response or the present application in 



SNELL & WILMER L.L.P. 

400 E. Van Buren 

One Arizona Center 

Phoenix, Arizona 85004 

Phone: 602-382-6228 

Fax: 602-382-6070 

Email: hsobelman@swlaw.com 



general. 




Dated: July 30, 2004 
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